Dr. Windows 3/dr win3.zip/dr win3/DATABASE/SECURE.ZIP/SECUR11.TXT

Text File | 1993-09-30 | 33KB | 618 lines

Microsoft Access Security
Last Updated:  09/15/93

Purpose
The purpose of this document is to explain the Microsoft Access security
model.  The hope is that if the user understands the intricacies of
security, and is conscientious, he will be able to safely and
successfully use Microsoft Access security in his databases.

Examples of scenarios that have caused difficulty for people in the past
have been set apart under the heading of Gotcha.  These are intended to
give practical examples of common misunderstandings, and to explain why
Microsoft Access security works the way it does.

This document is applicable to Microsoft Access versions 1.0 and 1.1, as
well as to the Microsoft Access Distribution Kit (ADK).  Features new to
Microsoft Access 1.1 and the ADK are called out with New for 1.1.

Disclaimer:  There are several places in this document where the
Microsoft Access sytem tables (those MSys*) are referred to.  In spite
of this, these tables are officially "undocumented", and are subject to
change in future versions.  Any attempts to read from or especially to
write to these tables will most almost certainly fail future versions of
Microsoft Access.
Overview
Microsoft Access security consists of 2 parts which are stored in
different places.  Information regarding the permissions that users and
groups have on the objects in a database is stored in the database
itself.  This way the permission information travels with the .mdb file
in which the objects exist.  All other security information is stored in
the SystemDB specified in msaccess.ini.  The default SystemDB is
system.mda.  Information stored in the SystemDB includes:  which Users &
Groups exist;  which Groups each User belongs to;  and User logon
passwords.  In Microsoft Access parlance, a SystemDB defines a
"Workgroup".

Note:  Retail Microsoft Access looks for the file msaccess.ini to find
it's settings, including SystemDB.  Applications created with the ADK
can specify any file for these settings (e.g. myapp.ini.)  For the
purposes of this document, msaccess.ini and myapp.ini are
interchangeable.
Logging On
Each User and Group has associated with it a Security ID (SID).  The SID
is a binary string that uniquely identifies the User or Group.  When a
user logs on, Microsoft Access looks in the MSysAccounts table of the
SystemDB for a user of the same name (case-insensitive).  If a user with
the same name is found, it then validates the password (case-sensitive).
If the password matches, the SID of the user is retrieved and saved in
an internal structure.  The password is only used to validate the user
when he logs on.  Other than validating the identity of the user when he
logs on, it has no effect on security.

By default, Microsoft Access first attempts to logon as the user Admin,
with a blank password.  If this logon fails, the user is presented with
the Logon dialog.  If a user name and password were specified on the
command line (using the /USER and /PWD flags), Microsoft Access first
tries to logon using that user name and password.  If this logon fails,
the user is presented with the Logon dialog.  Once logged on, the user's
SID is retrieved.  This SID is used for all subsequent security
operations within Microsoft Access.
Users and Groups
Each user can be a member of 1 or more groups.  Users & Groups share the
same namespace.  This means that you can't have both a group and user
with the same name.

Microsoft Access defines 3 default groups:  Admins, Users, and Guests.
Whenever a user is added to the SystemDB, they are automatically given
membership in the group Users, and they cannot be removed from the Users
group.  There is one exception to this rule---the user Guest CAN be
removed from the Users group.  The Admins group must always have at
least one member.

Microsoft Access defines 2 users:  Admin and Guest.  The user Admin is a
member of the Admins and Users groups.  The user Guest is a member of
the Guests group (only).

The pre-defined groups (Admins, Users, and Guests) cannot be deleted.
The user Guest cannot be deleted, though the user Admin CAN if there is
at least one other member of the Admins group.  Chapter 25 of the Access
Users Guide recommends deleting the Admin account.  The only reason for
this recommendation is so that you don't accidentally create any objects
using this account.  Objects created by Admin cannot be secured.

Each user and group has a SID associated with it.  The SIDs of the Users
and Guests groups, and of the Admin and Guest users, are the same in all
Microsoft Access installations.  The SID of the Admins group, however,
is unique across all Microsoft Access installations.  This prevents
someone who is in the Admins group of one SystemDB from being able to
have the permissions of the Admins group of any other SystemDB.

Gotcha:  If you delete the user Admin, and then create
another user named Admin, the SID of the new Admin will NOT
be the same as the SID of the Admin that exists in an
unsecure system.  This is because the Admin user that you
create will have a different PIN that the Admin user that
exists in a freshly-installed SystemDB.

If you setup from the Microsoft Access disks, the SID of the Admins
group is a function of the serial number of the Setup disk and the User
and Company names given (case-insensitive).  Therefore, it is critical
that the disks used to install Microsoft Access be kept in a safe place,
and that the User and Company names be recorded.

New for 1.1:  You can also create a SystemDB by running the Change
Workgroup utility.  Using Change Workgroup, you are able specify a
Personal Identification Number (PIN) in place of the disk serial number,
as well as any User and Company names.  This PIN can be any alphanumeric
string, up to 20 characters long.  The the SID of the Admins group will
be determined by these values (also case-insensitive).

In the event that the SystemDB has to be recreated, you must either have
the same installation disks, or have recorded the PIN, User name, and
Company name used to create it.  Because the Change Workgroup
functionality removes the connection between the original disks and
Access security, this is the recommended method of creating a SystemDB.

The SIDs of users and groups that you create are a function of the user
or group name (case-sensitive) and Personal Identification Number (PIN)
that you specify.  For this reason it is critical that the user and
group names and their PINs be recorded.  If there is ever a need to
recreate the SystemDB, you will need the name and PIN of each user and
group that was in the SystemDB.  Note that by using different PINs, it
possible for users and groups in different SystemDB's to have the same
name, but they will actually be different accounts as far as Microsoft
Access security is concerned because they have different SIDs.

Gotcha:  When you setup Microsoft Access, the User and
Company names are written to Disk #1.  If you then give
anyone else your disks to setup from, Microsoft Access
doesn't prompt for the User and Company name.  The Admins
group in the SystemDB that is created will have the same SID
as the Admins group in your SystemDB.  This means that
anyone who uses that new SystemDB will have all the
permissions that you do, in any databases that you have
permissions.  While this functionality wasn't intended as a
form of copy protection, it is a good incentive to abide by
the License Agreement.  It is also a good reason to create
your SystemDB using the Change Workgroup utility in
Microsoft Access 1.1
Permissions
There are 2 types of permissions:  Explicit and Implicit.  Explicit
permissions are those given directly to a user.  When they are granted,
no other users are affected.  Implicit permissions are those granted to
a group.  When they are granted, all users who are members of the group
get the permissions of the group.  Implicit permissions belong to the
group, not the